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DESCRIZIONE dell ' invenzione industriale dal titolo: 
" Procedimento e sistema per l'erogazione controllata 
di servizi numerici quali, ad esempio, servizi tele^ 
matici multimediali " 

di: CSELT - Centro Studi e Laboratori Telecomunica- 
zioni S.p.A., nazionalita italiana, Via G. Reiss Ro- 
moli, 274 - Torino 

Inventori designati: Massimo BALESTRI , Gianluca. DE 
PETRIS 

Depositata il : 11 agosto 1998 T 0 98A 0 Q Q 7 Q 5 

* * * 

TESTO DELIA DESCRIZIONE 
La presente invenzione si riferisce all'eroga- 
zione controllata di servizi numerici quali, ad 
esempio, servizi telematici multimediali, ed e stata 
sviluppata con particolare attenzione alia possibile 
applicazione nell'ambito della cosiddetta iniziativa 
OPIMA (Open Platform Initiative' for Multimedia Ac- 
cess) . 

Una descrizione delle finalita e dei criteri 
che regolano tale iniziativa e accessibile alia data 
di deposito della presente domanda sul sito Internet 
http : //www . cselt . it/uf v/leonardo/opima . 

Ulterior! informazioni di contest© sono desumi- 
bili ad esempio dalla norma CENELEC EN 50221, deno- 
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minata "DVB Common Interface Specification for Con- 
ditional Access and other Digital Video Broadcasting 
Decoder Applications" o ancora nel documento DAVIC . 
1.3 Part 10: "Basic Security Tools for Davie 1.3", 
pubblicato nel novembre 1997 su CD-Rom disponibile 
presso la Segreteria DAVIC c/o Societa Italiana 
Avionica S.p.A., Strada Antica di Collegno, 235; I- 

10146 Torino. 

L'invenzione e pero suscettibile di trovare ap- 
plicazione in tutte quelle situazioni in cui si de- 
sideri realizzare un sistema tale da consentire ad 
un utilizzatore o utente di avere accesso, con un 
unico decodificatore, ad informazioni codificate di 
fornitori (provider) diversi . L'invenzione pud quin- 
di trovare impiego in servizi diffusivi via satelli- 
te o cavo di tipo numerico, ad esempio per la forni- 
tura di contenuti audiovisivi a pagamento, anche di 
tipo interattivo. Un sistema secondo l'invenzione 
pud essere realizzato all ' interne di un decodifica- 
tore del tipo correntemente denominato Set Top Box 
(STB), nell'ambito di un personal computer, oppure 
integrate direttamente , ad esempio, in un ricevitore 
quale un ricevitore televisivo con interfaccia di 

tipo numerico. 

in questo contesto sono gia state proposte e 



sperimentate soluzioni in cui l'accesso alle infor- 
mazioni (tipicamente un programma televisivo) pre- 
suppone la disponibilita, presso l'utente, di un di- . 
spositivo decodificatore, essenzialmente di tipo 
proprietario del fornitore del servizio. In altre 
parole, un determinate) dispositivo decodificatore 
consente di ricevere soltanto i programmi trasmessi 
da un certo fornitore di servizi o, al piu, da un 
ristretto numero di fornitori che adottano le stesse 
modalita di erogazione dei servizi. 

In generale, per poter accedere a fornitori di- ^ 
versi, l'utilizzatore e perd costretto a prowedersi j 
di una molteplicita di dispositivi diversi, usando 

alternativamente ora l'uno, ora 1 ' altro dispositivo. 
Tentativi di conseguire un certo grado di stan- 

dardizzazione sono gia stati compiuti ad esempio con 

la definizione, da parte del Forum Internaz ionale 

DAVIC, della cosiddetta interfaccia CAO e, soprat- 

tutto, con la definizione della cosiddetta interfac- 
cia CA1, illustrata in dettaglio nel documento DAVIC 

1.3 gia citato in precedenza. 

In sostanza, le suddette due interfacce operano 

ai due livelli indicati rispettivamente con linee a 
tratto e punto nello schema della figura 1, destina- 
to ad essere utilizzato per illustrare tanto le so- 
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luzioni secondo la tecnica nota quanto la soluzione 
secondo 1 ' invenzione . 

In tale schema i riferimenti SP ed U indicano, 
rispettivamente, un fornitore (provider) di servizi 
informativi ed un utilizzatore o utente degli stes- 
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Tali servizi possono essere servizi informativi 
diversi, quali (ma senza limitazione a): programmi 
audio e/o televisivi, in particolare erogati secondo 

modalita di richiesta e pagamento diversi, servizi a ^ 
valore aggiunto, servizi pubblicitari, anche a pre- 
mio, servizi in abbonamento o erogati sulla base di 
buoni (coupon), servizi informativi yari (bancari e 
di borsa, sul traffico, di localizzazione, ecc . ) , 
giochi, distribuzione di software, televendite, ser- 
vizi bancari a distanza, servizi di rilevazione de- 
moscopica, anche di tipo interattivo. 

Sempre nello schema della figura 1 il riferi- 
mento D indica il mezzo (diffusione via cavo, via 

satellite, terrestre, in rete dedicata, su Internet, 

satellite, BEffiilSSS! 
ecc.) attraverso il quale 1 - inf ormazione generata JHHH 

dal fornitore SP perviene al sistema di ricezion /^^^^M 
STB dell 'utilizzatore U. |uj o 

Nello standard DAVIC 1.3 gia citato in prece^ , ^ ^ 
denza, tale informazione e presente sotto forma di\^!2^ 
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un flusso dati MPEG (acronimo per Moving Picture Ex- 
pert Group) , in particolare come un flusso codif ica- 
to secondo le relative normative ISO/IEC 13 818 
(MPEG-2) . In tale flusso vengono inseriti messaggi 
noti rispettivamente come ECM ed EMM. L ' acronimo 
ECM, che sta per Entitlement Control Message, iden- 
tifica i messaggi di controllo associati ad un ser- 
vizio. L' acronimo EMM, che sta per Entitlement Mana- 
gement Message, identifica invece i messaggi di ge- 
stione delle autorizzazioni alia fruizione di servi- 
zi associati ad un utente. 

Nell'unita STU (owerosia Set Top Unit, che in- 
sieme al blocco di sicurezza indicato complessiva- 
mente con SD costituisce il sistema di ricezione STB 
a disposizione dell 'utente U) e presentato in primo 
luogo un blocco ricevitore 100 destinato a realizza- 
re la ricezione a livello hardware (demodulazione, 
sincronizzazione, ecc . ) del flusso dati in ingresso. 
Quest 'ultimo e destinato ad essere inviato verso il 
blocco SD ed in particolare verso un filtro 101 ed 
un blocco di decifrazione o decriptazione 102. 

I segnali inviati secondo lo standard MPEG pos- 
sono essere crittograf ati cosi da consentirne la 
lettura in chiaro soltanto dagli utilizzatori abili- 
tati con un'opportuna chiave . 



La funzione di decriptazione e pilotata, nel- 
l'ambito dell'unita STU, dal modulo di gestione 103 
che invia tramite una rispettiva interfaccia di co- 
mando istruzioni verso un modulo 104. Quest 'ultimo 
funge, nell'ambito del blocco SD # da elemento di ge- 
stione della sicurezza (cosiddetto Security Mana- 
ger) . In pratica, la funzione del modulo 104 e quel- 
^a di interagire con il filtro 101, con il modulo di 
decifrazione o decriptazione 102 e con un'unita di 
utente 105 per fornire verso il modulo 102 una chia- 

ve di decifrazione tale da consentire al modulo 102 ^ 

CO 

stesso di decifrare il segnale in arrivo dal ricevi- S 
tore 100. Questo segnale pud cosl essere reso in 
chiaro e trasferito a un demultiplatore 106 e ad un 
decodif icatore 107 (owero ad una catena di elabora- 
zione equivalente) contenuti nell'unita STU in vista 
dell 1 erogazione verso 1' utente U. 
£ Nei sistemi. piu tradizionali a cui si e fatto 
cenno in precedenza (del tipo di quelli che imple- 
mentano la cosiddetta interfaccia CA0 nella termino- 
logia corrente in ambito DAVIC) la standard! zzazione 
del sistema di ricezione STB in funzione dei vari 
fornitori dei servizi SP si limita alia sola unita 
STU. 

Tutto quanto sta al disotto della linea a trat- 
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to e punto che nella figura 1 identifica l'interfac- 
cia CAO costituisce una parte di dispositivo specia- 
lizzato in funzione di un determinate) fornitore di 
servizi . 

L'adozione dell 'interf accia CA1 consente di 
standardizzare anche l'unita SD, spostando l'esigen- 
za di specializzazione ad un livello piu basso, os- 
sia a quello dell'unita di utente 105 per la quale e 
prevista la realizzazione in forma amovibile, in 
particolare sotto forma di una cosiddetta "smart 
card" . 

Tuttavia, anche ricorrendo alia realizzazione 
come smart card, i problem! delineati in precedenza 
non vengono comunque risolti ma semplicemente tra- 
sferiti ad un livello diverse 

L'utente o utilizzatore che desideri ricevere 
l'informazione da fornitori SP diversi dovra in ge- 
nerale munirsi di tante unita di utente 105, dunque 
di tante smart card diverse, una per ciascun forni- 
tore. 

Oltre a doversi prowedere di piu smart card, 
l'utente dovrebbe comunque di volta in volta ricon- 
f igurare il suo sistema di ricezione in funzione del 
fornitore dei servizi che si desiderano ricevere, ad 
esempio inserendo nel sistema la smart card corri- 
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spondente . 

La scarsa praticita di questo modo di operare e 
evidente, soprattutto se si tiene conto del fatto 
che in uno scenario del tipo di quello dell ■ inizia- 
tiva OPIMA si desidera fornire all'utente modalita 
di selezione dei fornitori SP sostanzialmente analo- 
ghe a quelle normalmente adottate nella ricezione 
dei programmi televisivi: in pratica la possibility ■ 
di scegliere fornitore e servizio tramite una sem- 
plice azione esercitata su un telecomando . 

Almeno in linea di principio gli inconvenient i 
sopra delineati potrebbero essere risolti prevedendo 
l'inserimento di piu unita di utente 105 nel sistema 

di ricezione. 

Anche in modo indipendente da ogni considera- 
zione sulla complessita del sistema, questa soluzio- 
ne non risolverebbe comunque il problema legato al- 
l'esigenza, per 1' utente, di munirsi di piu unita di 
utente 105. 

La presente invenzione si prefigge lo scopo di 
fornire una soluzione in grado di evitare gli incon- 
venient! delineati in precedenza, in particolare in 
relazione alia possibile adozione delle interfacce 
definite come CAO e CA1, pur conservando general! 
doti di conformita con tali interfacce. 



Secondo la presente invenzione, tale scopo vie- 
ne raggiunto grazie ad un procedimento per 1 ' eroga- 
zione di servizi avente le caratteristiche richiama- 
te in modo specifico nelle rivendicazioni che seguo- 
no. L 1 invenzione ha anche per oggetto il relativo 
sistema . 

L ■ invenzione verra ora descritta, a puro titolo 
di esempio non limitativo, con riferimento ai dise- - 
gni annessi, nei quali: 

- la figura 1, rappresentativa - in termini ge- 
nerali - anche delle soluzioni secondo la tecnica 
not a, e gia stata esaminata in precedenza, 

- la figura 2 illustra, sot to forma di uno 
schema a blocchi funzionale corrispondente al model- ^ 
lo di riferimento OPIMA (OPIMA Reference Model) una 
possibile forma di attuazione dell ' invenzione , e 

- la figura 3 illustra, sotto forma di un dia- 
gramma di flusso, una possibile' sequenza di funzio- 
namento di un sistema secondo 1 ' invenzione . 

Nella figura 2 elementi identici o corrispon- 
denti a quelli gia descritti con riferimento alia 
figura 1 sono stati indicati con gli stessi riferi- 
menti che gia appaiono nella figura 1. 

Cio vale in particolare per il fornitore dei 
servizi SP, il canale di distribuzione D verso l'u- 
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tente U, l'unita STU e 1 ' ideale collocazione delle 
interfacce CAO e CA1 . 

II complesso delle funzioni illustrate con ri- 
ferimento alia figura 1 facendo riferimento ai modu- 
li 101, 102, 104 e svolto, nello schema secondo 
l'invenzione della figura 2, da un complesso di ele- 
ment! rappresentato dai blocchi TMW1, TMW2 e VM. La 
sigla TMW utilizzata per entrambi i blocchi TMWl e . 
TMW2 sta ad indicare il fatto che tali blocchi ven- 
gono normalmente realizzati a livello di cosiddetto 
"trusted middleware" (ossia di software che realizza 
funzioni di sicurezza) . 

in sintesi, la soluzione secondo l'invenzione 
pu6 essere vista come uno sviluppo della soluzione 
basata sull • interf accia CA1 . Nella soluzione secondo 
l'invenzione la smart card 105 oltre a contenere una 
chiave crittograf ica non modif icabile ne leggibile 
dall'esterno, e in grado di ricevere, verificare, 
immagazzinare ed eseguire un algoritmo che consente 
la fruizione dei servizi erogati da un determinate 
f ornitore . 

La fase di verifica mira a provare l'autentici- 
ta e l'integrita dell ' algoritmo prima che venga im- 
magazzinato nella smart card, ed e basata sul con- 
trollo di una firma crittograf ata digitale eseguita 
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da una Autorita di Certif icazione riconosciuta dai 
fornitori dei servizi e dai produttori delle smart 
card. 

L ' esecuzione dell 1 algoritmo specif ico del for- 
nitore di servizi permette di decifrare i messaggi 
EMM/ECM proprietari del fornitore di servizi stesso 
e di alimentare il modulo di decifrazione 102 che 
prowede a mettere in chiaro i servizi richiesti 
dall'utente, consentendone . 

In questo modo l'utente non ha piu necessita di 
prowedersi di piu unita 105 per poter ricevere in- 
formazioni da fornitori diversi. 

Secondo l'invenzione e infatti sufficiente di- 
sporre, ad esempio, di un'unica smart card, di tipo 
universale, e le informazioni relative alia specia- 
lizzazione, necessarie per poter ricevere in chiaro 
le informazioni di un determinato fornitore, possono 
essere scaricate direttamente dai sistema nella 
smart card, sfruttando la possibilita della stessa 
di eseguire i programmi scaricati tramite il suo 
chip, e lo strato di software ad esso associate qui 
rappresentati come una macchina virtuale VM. 

Il tutto con l'ulteriore possibilita, da parte 
del fornitore, di controllare e verificare l'effet- 
tiva abilitazione di un particolare utente a riceve- 
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re determinati programmi . E 1 infatti soltanto a se- 
guito della awenuta iscrizione di un determinate) 
utente (ad esempio a seguito della sottoscrizione di 
un abbonamento) all ' insieme degli utenti abilitati a 
ricevere un dato servizio che il fornitore prowede 
a diffondere 1 ' inf ormazione che, elaborata a livello 
di smart card 105, consente all' utente stesso di ri- 
cevere il servizio. 

Da quanto precede risulta altresi evidente che, 
pur essendo preferita (per motivi meglio spiegati 
nel seguito) l'attuazione a livello di un sopporto 
mobile quale una smart card, la stessa funzione pud 
essere svolta anche in modo diverso, ad esempio sot- 
to forma di una funzione circuitale compresa nel si- 
stema STB dell' utente. 

A differenza delle interfacce CAO e CA1 de- 
scritte in precedenza, che sono intrinsecamente in- 
terfacce a livello fisico, la soluzione secondo 
l'invenzione e suscettibile di essere implementata a 
livello di programmazione , in particolare mediante 
una smart card, quale, ad esempio, una cosiddetta 
Java Card. 

I termini "Java" e "Java Card" sono marchi re- 
gis trati della Sun Microsystems. La relativa descri- 
zione, in particolare per quanto riguarda la defini- 
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zione di cosiddette API (acronimo per Application 
Programming Interface) e pubblicamente disponibile, 
alia data di deposito della presente domanda, presso 
il sito Internet http://java.sun.com/products/java- 

card. 

Sotto questo punto di vista, la soluzione se- 
condo l'invenzione puo essere identificata come un 
nuovo livello di interfaccia, indicato nella figura • 
2 come CA2 per conformita con le denominazioni CAO e 
CA1 utilizzate in precedenza, corrispondente in pra- 
tica ad un livello intermedio dell'unita di utente 
105. All'atto pratico, la soluzione secondo l'inven- 
zione prevede che il cosiddetto "trusted middleware" 
previsto dal modello di riferimento OPIMA sia suddi- 
viso in una parte statica TMW1, compresa, secondo la 
soluzione illustrata nella figura 2, nel modulo STB, 
ed una parte dinamica TMW2 , compresa nell'unita di 
utente 105. 

II complesso di funzioni rappresentato da TMW1 
comprende in particolare un modulo SP- la cui fun- 
zione e essenzialmente quella di estrarre un algo- 
ritmo specific© del fornitore SP a partire dal flus- 
so di dati MPEG proveniente dal ricevitore 100 (fi- 
gura 1) per caricarlo nell'unita di utente 105 come 
parte specif ica. Di preferenza tale algoritmo e in- 



14 



serito come flusso di dati privati in conformity con 
lo standard ISO/IEC 13818 gia menzionato. La parte 
rimanente nell'insieme di funzioni TMW1 e costituita 
dal descrambler 102 e dalle relative funzioni rap- 
presentate dai moduli 101 e 104 nello schema della 
figura 1. H complesso di parti e funzioni TMW1 ri- 
sulta pertanto completamente definito e del tutto 
indipendente dal fornitore SP di volta in volta co- . 
involto e di conseguenza e di tipo standardizzato . 
in pratica, la funzione indicata come TMW2 e identi- 
ficata da un algoritmo specif ico del singolo forni- 
tore SP che viene scaricato nell'unita di utente 105 
in modo sicuro (ad esempio in quanto prowisto di 
firma crittograf ica) attraverso la funzione SP'. 

In questo modo 1' algoritmo scaricato e suscet- 
tibile di essere eseguito nell'unita di utente 105 
in un ambiente sicuro, proprio per le ben note doti 
di resistenza alia manomissione delle smart card. 

Questo spiega il perche, pur essendo in via di 
principio attuabile anche ricorrendo ad un circuito 
o ad una funzione incorporata nel sistema STB del- 
1 "utente, la soluzione secondo 1 ■ invenzione viene 
realizzata di preferenza a livello di una unita di 
utente 105 costituita da una smart card. Questa 
scelta consente anche di sostituire facilmente una 
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smart card eventualmente danneggiata o alterata. 

Nell'impiego, quando 1 ' utilizzatore U sceglie 
un particolare fornitore SP (cio pud essere fatto 
tramite una normale operazione di selezione attuata 
agendo su un telecomando - ndn illustrate ma asso- 
ciate in modo noto al sistema STB - secondo le nor- 
mal! modalita adottate, ad esempio, per la selezione 
di un programma televisivo) un cosiddetto applet ge- 
nerate dal fornitore SP in questione viene trasferi- 
to verso il sistema STB in vista del caricamento 
nella rispettiva unita 105. Come noto, per applet si 
intende un insieme di istruzioni Java che realizza 
un determinate algoritmo. La diffusione puo aweni- 
re, ad esempio, nel case di trasmissioni diffuse 
tramite onde radio sfruttando la conf igurazione a 
giostra (carousel) adottata per la diffusione dei 
dati MPEG- 2 DSM-CC (acronimi per Digital Storage Me- 
dia Command Control) . 

in questo modo, nell'ambito della funzione TMW1 
il filtro 101 (f igura 1) viene programmato in vista 
dell ' estrazione dei dati EMM, specific! del singolo 

utente abilitato. 

I messaggi EMM possono essere cosi letti e de- 
cifrati in vista dell ' interpretazione dei dati con- 
tenuti nei messaggi ECM. E' cosi possibile procedere 
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all 1 estrazione della chiave di decifrazione CW rela- 
tiva al servizio che viene inviata verso il descram- 
bler 102 , in modo da consentire la funzione del ser- 
vizio da parte dell'utente U attraverso il demulti- 
platore 106 e il decodif icatore 107. 

Naturalmente, e anche possibile prevedere fun- 
zioni addizionali, quale quella che prevede il tra- 
sferimento sicuro verso il fornitore SP di informa- 
zioni specif iche relative al servizio erogato, quale 
ad esempio inf ormazioni inerenti all'entita di con- 
sumo del servizio richiesto. 

Un esempio specifico di f unzionamento secondo i 
criteri generali appena richiamati e illustrato nel 
diagramma di flusso della figura 3. 

A partire da un passo iniziale 2 00, il passo 
indicato con 2 01 rappresenta la scelta, da parte 
dell'utilizzatore, di un particolare fornitore SP. 
Questo passo puo essere attuato, ad esempio, sinto- 
nizzando - in modo noto - il sistema STB su una cer- 
ta frequenza. 

Come risultato (passo 2 02) il sistema STB in 
questione comincia a ricevere dal fornitore SP il 
flusso di trasporto dei dati, ad esempio nel formato 
MPEG-2, trasmesso dal fornitore SP. 

II passo 203 rappresenta 1 1 estrazione della 
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funzione TMW2 (di tipo dinamico) da parte della fun- 
zione SP 1 . 

Dopo aver ripristinato (nel passo 204) 1'unita 
utente 105, nel successive^ passo 205 il sistema STB 
installa nella stessa (ad esempio come applet di Ja- 
va Card) la funzione TMW2 . II sistema STB richiede 
poi (passo 206) alia stessa unita 105, in particola- 
re alia parte di macchina virtuale VM che e in grado 
di elaborare i dati estratti, come inizializzare la 
funzione di filtro, rappresentata dal blocco 101 
nella f igura 1 . 

A questo punto (passo 2 07) il sistema STB co- 
mincia ad inviare verso I'unita di utente 105 i dati 
EMM filtrati completando cosi 1 ■ abilitazione della 
comunicazione f ornitore/utente . Quest 1 ultimo puo al- 
lora scegliere (passo 208) il servizio desiderato. A 
questo punto il sistema STB comincia a filtrare i 
segnali ECM associati al servizio prescelto invian- 
doli verso I'unita di utente 105 dove si verifica 
(passo 210) se 1 » utilizzatore e abilitato ad accede- 
re al servizio. 

In caso di esito negativo (utente non abilita- 
to) , il funzionamento evolve verso un'ulteriore fase 
di scelta di un eventuale altro servizio (passo 216 
di cui si dira nel seguito) . 
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Se, al contrario, l'utente risulta abilitato 
(esito positivo del passo di confronto 210) in quan- 
to registrato come tale presso il fornitore SP, in 
particolare in relazione al servizio prescelto, i 
dati ECM vengono decifrati dall'unita 105 (passo 
211) restituendo le rispettive parole di controllo 
verso il sistema STB (passo 212) . 

In questo modo la funzione TMW1 (statica) del 
sistema STB e in grado di decifrare il servizio por- 
tandolo in chiaro (passo 213) in vista dell'eroga- 
zione all'utente (passo 214) attraverso i moduli 106 
e 107. 

II passo 215 e diretto a verificare se l'uten- 
te, con 1 ' applicazione al sistema STB di un ordine 
(ad esempio impartito tramite telecomando) abbia 
espresso la volonta di interrompere la fruizione del 
servizio o se il servizio stesso sia terminate 

Se non e cosi (esito negativo del passo 215) il 
funzionamento ritorna a monte del passo 211, con la 
possibility di tener conto di un'eventuale periodica 
variazione della chiave di decifrazione CW. 

In caso di esito positivo del passo 215, in un 
successivo passo 216 si verifica se l'utente sia in- 
tenzionato a usufruire di un nuovo servizio. Come 
gia detto, il funzionamento pud evolvere verso il 
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passo 216 anche nel caso di esito negativo del passo 
210, cosl da consentire ad un utente non abilitato 
alia fruizione di un determinates servizio di sce- 
gliere un servizio diverso. 

L' esito negativo del passo 216 determine 1 ' evo- 
luzione verso una fase terminale 300. Si apprezzera 
che questa non corrisponde di solito ad un vero e 
proprio arresto del sistema STB ma soltanto al rag- • 
giungimento di uno stato di attesa (idle) . 

L * esito positivo del passo 216 determina il ri- 
torno verso il passo 2 01 di scelta di un nuovo for- 
nitore owero verso il passo 208 di scelta di un 
nuovo servizio erogato dallo stesso fornitore uti- 
lizzato in precedenza a seguito dell ' esito di un 
corrispondente passo di scelta 217. 

Naturalmente, fermo restando il principio del- 
l'invenzione, i particolari di realizzazione e le 
forme di attuazione potranno essere ampiamente va- 
riati rispetto a quanto descritto ed illustrate 
senza per questo uscire dall'ambito della presente 
invenzione, cosi come def inita dalle rivendicazioni 
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RIVENDICAZIONI 
1. Procedimento per l'erogazione controllata di 
servizi numerici nell'ambito di una pluralita di 
fornitori (SP) ed utenti (U) , in cui detti servizi 
sono identificati da rispettivi flussi di dati codi- 
ficati erogati da detti fornitori (SP) e gli utenti 
sono prowisti di mezzi di ricezione (STB) per rice- 
vere detti flussi di dati, i mezzi di ricezione es- - 
sendo selettivamente abilitati alia fruizione di 
servizi determinati attraverso una rispettiva unita 
di utente (105)., caratterizzato dal fatto che com- 
prende le operazioni di : 

- incorporare in. detti flussi di dati codifica- 
ti almeno un algoritmo di abilitazione alia fruizio- 
ne di rispettivi servizi determinati (TMW2) , 

- incorporare in detti flussi di dati codifica- 
ti un rispettivo codice identif icativo (EMM) per 
ciascun utente (U) da abilitare alia ricezione di un 
determinato servizio, 

- associate a detta unita d' utente (105) una 
funzione elaborativa (VM) suscettibile di riconosce- 
re ed eseguire detto almeno un algoritmo di abilita- 
zione sulla base di detto codice identif icativo per 
abilitare i mezzi di ricezione (STB) del rispettivo 
utente alia fruizione di detto servizio. 
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2. Procedimento secondo la rivendicazione 1, ca- 
ratterizzato dal fatto che comprende l'operazione di 
configurare detta unita di utente (105) quale sup- 
ported elaborativo mobile assegnato univocamente ad 
uno di detti utenti (1) ed associabile selettivamen- 
te a detti mezzi di ricezione (STB) , detti mezzi di 
ricezione (STB) essendo di tipo generalizzato comune 
a piu utenti di detta pluralita (U) . 

3. Procedimento secondo la rivendicazione 2, ca- 
ratterizzato dal fatto che comprende l'operazione di 
configurare detto support o elaborativo mobile come 
smart card . 

4. procedimento secondo una qualsiasi delle prece- 
dent! rivendicazioni, caratterizzato dal fatto che 
comprende le operazioni di : 

- associare a detti mezzi di ricezione (STB) 
una funzione di trusted middleware (TMW) , 

- configurare detta funzione di trusted middle- 
ware in una parte statica (TMW1) , residente su detti 
mezzi di ricezione (STB) , ed in una parte dinamica 

(TMW2) selettivamente trasferibile su detta unita di 
utente (105) in vista dell ' esecuzione di detto alme- 
no un algoritmo da parte di detta funzione elabora- 
tiva (VM) . 

5. Procedimento secondo una qualsiasi delle prece- 
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denti rivendicazioni, caratterizzato dal fatto che 
comprende le operazioni di : 

- configurare detti flussi di dati come flussi 
di dati di tipo MPEG, contenenti messaggi di tipo 
EMM, 

- inserire detto codice identif icativo nei mes- 
saggi di tipo EMM, 

- attivare, tramite detta unita di uteiite / 
(105) , a seguito della ricezione di detto almeno un 
algoritmo, lo svolgimento delle seguenti funzioni: 

- estrazione, lettura e decifrazione dei mes- 
saggi EMM contenuti nel flusso di dati rice- 
vuto, 

- interpretazione di detto codice identif icati- 
vo contenuto nei messaggi EMM, 

- esecuzione di detto almeno un algoritmo di 
abilitazione sulla base di detto codice iden- 
tif icativo. 

6. Procedimento secondo una qualsiasi delle prece- 
denti rivendicazioni , caratterizzato dal fatto che 
detto almeno un algoritmo di abilitazione viene in- 
corporato in un flusso di dati privati nell'ambito 
di detti flussi di dati. 

7. Procedimento secondo una qualsiasi delle prece- 
denti rivendicazioni, caratterizzato dal fatto che a 
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seguito della ricezione di detto almeno un algorit- 
mo, detta funzione elaborativa (VM) abilita detti 
mezzi di ricezione per il funzionamento quali tra- 
smettitori per emettere informazioni relative all'e- 
rogazione del servizio stesso. 

8. Sistema per l'erogazione controllata di servizi 
numeric! nell'ambito di una pluralita di fornitori 
(SP) ed utenti (U) in cui detti servizi sono identi- 
ficati da rispettivi flussi di dati codificati ero- 
gati da detti fornitori (SP) e gli utenti sono prov- 
visti di mezzi di ricezione (STB) per ricevere detti 
flussi di dati, i mezzi di ricezione essendo selet- 
tivamente abilitati alia fruizione di servizi deter- 
minati attraverso una rispettiva unita di utente 
(105), caratterizzato dal fatto che: 

- detti fornitori (SP) sono conf igurati per in- 
corporare nei rispettivi flussi di dati codificati, 
almeno un algoritmo di abilitazione alia fruizione 
di rispettivi servizi determinate nonche per incor- 
porare in detti flussi di dati codificati, un ri- 
spettivo codice identif icativo (TMW2) , per ciascun 
utente (U) da abilitare alia ricezione di un deter- 
minate servizio, 

- dette unita d- utente (105) portano associata 
una funzione elaborativa (VM) suscettibile di rico- 
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noscere ed eseguire detto almeno un algoritmo sulla 
base di detto codice identif icativo per abilitare i 
rispettivi mezzi di ricezione (STB) del rispettivo 
utente alia fruizione di detto servizio. 
9. Sistema secondo la rivendicazione 8, caratte- 
rizzato dal fatto che dette unita di utente (105) 
sono configurate quali support! elaborativi mobili 
assegnati univocamente ciascuno ad uno di detti 
utenti (1) ed associabili selettivamente a detti 
mezzi di ricezione, detti mezzi di ricezione essendo 
di tipo generalizzato comune a piu utenti di detta 
pluralita (U) . 

10. Sistema secondo la rivendicazione 9, caratte- 
rizzato dal fatto che detti support! elaborativi mo- 
bili sono configurati come smart card. 

11. sistema secondo una qualsiasi delle precedent 
rivendicazioni 8 a 10, caratterizzato dal fatto che 

- detti mezzi di ricezione' (STB) portano asso 
ciata una funzione di trusted middleware (TOW) con- 
f igurata in una parte statica (TMW1) , residente su 
detti mezzi di ricezione (STB) , ed in una parte di- 
namica (TMW2) selettivamente trasferibile sulla ri- 
spettiva unita di utente (105) in vista dell'esecu- 
zione di detto almeno un algoritmo da parte di detta 
funzione elaborativa (VM) . 
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13 . Sistema secondo una qualsiasi delle precedent! 
rivendicazioni 8 a 11, caratterizzato dal fatto che 
detti fornitori di servizi erogano detti flussi di 
dati come flussi di dati di tipo MPEG contenenti 
messaggi di tipo EMM con detto codice identif icativo 
inserito in detti messaggi di tipo EMM, e detti mez- 
zi di ricezione comprendono: 

- mezzi di estrazione, lettura e decifrazione • 
dei messaggi EMM contenuti nel flusso di dati 
ricevuto, 

- mezzi di interpretazione (103, 104) per in- 
terpretare detto codice identif icativo conte- 
nuto nei messaggi EMM, e 

- mezzi elaborativi (VM) per eseguire detto al- 
meno un algoritmo di abilitazione sulla base 
di detto codice identif icativo . 

13. Sistema secondo una qualsiasi delle precedenti 
rivendicazioni 8 a 12, caratterizzato dal fatto che 
detti fornitori di servizi incorporano detto almeno 
un algoritmo di abilitazione in un flusso di dati 
privati nell ' ambito di detti flussi di dati. 

14. Sistema secondo la rivendicazione 13, caratte- 
rizzato dal fatto che i mezzi di ricezione sono at- 
tivabili da detta unita di utente (105) a seguito 
della ricezione di detto almeno un algoritmo per il 
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funzionamento quali trasmettitori per emettere in- 
formazioni relative all 1 erogazione del servizio 
stesso . 

15. Sistema secondo una qualsiasi delle rivendica- 
zioni 8 a 14, caratterizzato dal fatto che detta 
unita di utente (105) e configurata come Java Card. 
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